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Executive  Summary 

This  document  provides  a  concluding  summary  for  the  ARTUE-DTO  project.  It 
includes  an  Overview  of  the  project,  Conclusions ,  and  follow-on  Recommendations. 

A  Functional  Description  of  the  Dashboard  Display  and  the  associated  Progress 
Metrics  and  Agent  Alerts  give  context  for  the  recommendations.  References  are 
provided  for  project  documents  containing  additional  information  (e.g.,  detailed 
designs  and  transition  plans).  Lastly,  summary  descriptions  of  late  term  project 
investigations  are  included  as  attachments. 

1  Overview 

Autonomous  Response  to  Unexpected  Events  for  Defense  Terminal  Operations  (ARTUE-DTO) 
(R2D2)  is  a  Research,  Development,  Test,  and  Evaluation  project  sponsored  by  the  United  States 
Transportation  Command.  The  introduction  of  service-oriented  computing  and  Radio  Frequency 
Identification  (RFID)  technologies  present  opportunities  to  realize  substantial  improvements  in 
the  efficiency,  response  time,  and  throughput  of  transportation  operations,  while  minimizing  the 
unintended  consequences  of  unplanned  actions  prompted  by  unexpected  events.  Realizing  the 
benefits  of  these  technologies  requires  the  creation  of  intelligent  services  with  advanced 
reasoning  capabilities.  R2D2  is  proposed  to  improve  plan  de-confliction  and  re-planning  within 
the  ICODES  Single  Load  Planner  (SLP)  and  Terminal  Management  Module  (TMM)  domains 
through  the  application  of  ARTUE  reasoning  technology  that  was  developed  at  the  Naval 
Research  Laboratory  (NRL). 

R2D2  operates  above  individual  planning  and  execution  systems  to  provide  an  overarching 
perspective  of  the  interdependent  load  planning  activities  occurring  across  the  transportation 
network.  The  plans  at  a  given  node  have  dependencies  on  the  plans  at  other  nodes.  Significant 
changes  in  the  information  from  which  a  plan  was  derived  may  occur  during  planning,  and 
significant  deviations  from  the  planned  state  may  arise  during  execution.  These  planning 
problems  propagate  across  the  transportation  network,  compounding  their  operational  impact. 
R2D2  automatically  monitors  evolving  plan  and  execution  states  in  ICODES  SLP  and  TMM  to 
identify  planning  and  execution  discrepancies,  determine  potential  impacts,  and  derive 
recommendations  for  corrective  actions  as  appropriate. 

The  proof-of-concept  implementation  of  the  R2D2  Service  Oriented  Architecture  (SOA)  design1 
was  developed  and  demonstrated  in  the  context  of  a  load  planning  scenario  that  was  evolved 
over  the  course  of  the  project  performance.  The  final  R2D2  demonstration  comprises  a  multi- 
phased  ship  pre-stow  plan,  a  corresponding  as-loaded  plan,  and  a  supporting  TMM  terminal 
operations  plan  linked  in  a  dynamic  re-planning  collective.  As  execution  progresses,  significant 
discrepancies  with  the  pre-stow  plan  emerge.  The  R2D2  Dashboard  display  implements  a 
Continuous  Intelligence  paradigm  that  promptly  notifies  users  of  the  potential  issues  through 
Agent  Alerts  and  characterizing  Performance  Metrics  that  are  dynamically  updated  as  the 
operation  proceeds.  Users  accordingly  make  dynamic  adjustments  to  the  Load  Plan  in  SLP  or 
the  Operations  Plan  in  TMM  as  plan  execution  continues. 


1  See  the  ARTUE-DTO  Technical  Design  Report  for  a  detailed  R2D2  design  specification. 
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2  Conclusions 

The  following  conclusions  were  derived  from  the  performance  of  contracted  R2D2  project  tasks 
including  the  development  and  demonstration  of  the  R2D2  proof-of-concept  implementation. 

•  Service  Reuse:  The  existing  SOA  interfaces  that  were  developed  for  the  ICODES 
Hand  Held  Terminal  (HHT)  to  interface  with  TMM  and  SLP  prove  useful  as 
general  purposed  interfaces  for  the  development  of  new  enterprise  capabilities 
(e.g.,  R2D2)  that  are  external  to  ICODES  but  directly  compose  (i.e.,  reuse)  or 
collaboratively  interact  (i.e.,  interface)  with  ICODES  SLP  and/or  TMM  services. 

•  Domain  Independent  Rules:  Relatively  simple  rules  concerning  planned  and 
actual  cargo  type  and  position  in  the  context  of  the  available  space  and  time  can 
be  developed  that  apply  to  all  load-planning  domains  (i.e.,  Air,  Ship,  Rail,  and 
Yard)  and  effectively  assist  human  operators  in  identifying  potential  planning  and 
execution  problem — particularly  within  complex  multi-phased  load  plans 
involving  many  thousands  of  cargo  items. 

•  Linked  Load  Planning  and  Terminal  Operations:  R2D2  agent  configuration  can 
provide  temporal  context  to  the  essentially  atemporal  load  plan  constructs  of 
ICODES  SLP,  particularly  when  used  to  link  SLP  load  plans  to  the  fully  temporal 
TMM  representation  of  supporting  terminal  operations. 

•  ARTUE  Reasoning  Engine:  The  rules  implemented  for  the  R2D2  proof-of- 
concept  proved  to  execute  faster  using  an  ICDM-based  implementation  than  using 
the  NRL  developed  ARTUE  reasoning  engine.  Additionally,  the  ARTUE  engine 
was  found  to  require  specialized  uncommon  knowledge  of  the  LISP  programming 
language  for  its  rule  encodings  and  maintenance.  ARTUE  is  more  applicable  to 
applications  with  fewer  facts  (e.g.,  cargo  items)  and  a  large  number  of  complex 
domain  specific  rules. 

•  SOA  Capability  Development  and  Evaluations:  The  SOA  infrastructure  and 
capability  stack  of  ICODES  supports  the  rapid  development  of  new  experimental 
capabilities  directly  within  the  computing  context  of  the  enterprise;  however, 
availing  new  services  for  user  trial  and  evaluation  proves  more  difficult  as  the 
they  have  yet  to  receive  Authority  to  Operate  (ATO)  on  the  Government  networks 
hosting  the  production  system  environments  and  services  upon  which  they  are 
based. 

3  Recommendations 

As  the  project  concluded,  many  ideas  for  what  next  to  explore  were  conceptualized  by  the 
project  team.  These  were  consolidated  to  produce  the  following  recommendations  for  options  to 
consider  for  capitalizing  the  R2D2  technology  in  follow-on  phases. 
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•  Experimental  Tools  Area:  Consider  incorporating  an  Experimental  Tools  Area  in 
the  ICODES  Production  Environment  for  use  in  RTD&E  software  evaluation  and 
technology  transition  purposes.  A  significant  limitation  of  RTD&E  efforts  is  the 
ability  to  avail  them  to  real-world  user  communities  for  collaborative 
development  and  evaluation  in  the  context  of  real-world  operations.  The 
ICODES  SOA  platform  and  Web  portal  can  provide  potential  users  with 
convenient  access  to  R2D2  capabilities  in  a  controlled  and  secure  manner. 

•  Direct  Technology  Integration:  Consider  integrating  R2D2  technology  directly 
into  the  ICODES  Production  Environment.  R2D2  technology  can  be  exploited  in 
many  different  ways  by  the  existing  ICODES  services  and  applications.  For 
example,  the  experimental  application  of  R2D2  technology  for  container 
sequencing  is  perhaps  best  progressed  directly  in  TMM  in  the  context  of  current- 
proposed  software  change  requests  (SCRs).  The  reasoning  capabilities  of  the 
ARTUE  engine  can  be  employed  to  improve  the  automatic  load  planning  service 
utilized  by  SLP  and  other  ICODES  applications  as  another  example. 

•  Cross  Terminal  Applications:  Consider  using  R2D2  technology  for  the  automatic 
communication  of  significant  load  plan  changes  to  follow-on  ports  so  their 
discharge  and  pre-stow  plans  can  be  accordingly  adjusted.  For  example,  when  an 
as-loaded  plan  representing  a  ship’s  manifest  is  deposited  in  the  ICODES 
Information  Repository,  R2D2  can  be  extended  to  automatically  compare  it  the 
prior-deposited  pre-stow  plans  at  the  shipping  and  receiving  ports  and  send  email 
notification  to  the  load  planning  activity  at  the  receiving  port  if  re-planning  is 
advised. 

•  Dynamic  Yard  Applications:  Consider  R2D2  technology  combined  with 
increasingly  common  RFID  solutions  for  dynamic  container  placement 
applications.  ARTUE  can  improve  efficiency  in  new  ways.  Responsiveness  to 
individual  container  movements  can  be  provided  via  tablets  or  other  portable 
devices;  for  example,  when  a  container  is  moved  and  scanned,  R2D2  can  be 
modified  to  direct  the  operator  to  place  it  atop  a  stack  of  long-term  containers 
rather  than  atop  containers  that  must  soon  be  moved.  Every  container  move  saved 
is  efficiency  gained.  The  return  is  increased  as  the  technology  progressively 
looks  farther  into  the  future  and  considers  other  impacting  factors. 

•  Preposition  Shipping  Applications:  Consider  applying  R2D2  technology  to 
preposition  ship  loading  and  container  processing  problems  exemplified  by  those 
at  the  Marine  Ocean  Terminal  at  Sunny  Point  (MOTSU).  The  need  to  not  only 
frequently  move,  but  stuff,  un-stuff,  and  re-stuff  containers  in  the  context  of 
inspection  and  refurbishing  processes  presents  an  additional  layer  of  complexity 
upon  the  domain-independent  rules  provided  by  the  R2D2  Proof  of  Concept.  In 
addition  to  optimally  sequencing  the  stacking  and  servicing  of  containers,  the  goal 
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to  load  containers  such  that  any  build  number  is  accessible  within  four  (4)  lifts 
can  be  greatly  facilitated  by  extensions  to  the  container  stacking  rules  R2D2 
implements. 


4  Functional  Description 

R2D2  provides  users  with  Continuous  Intelligence  about  the  load  planning  operations  that  they 
have  configure  their  R2D2  Agents  to  monitor  for  them,  including  those  with  interacting  terminal 
and  load  planning  operations  occurring  within  and  across  globally  distributed  transportation 
facilities.  It  provides  visibility  of  cargo  across  transportation  modes  and  plan  phases  with  a 
Dashboard  Display  that  promptly  informs  users  of  significant  plan  deviations  through  use  of 
Performance  Metrics  and  Agent  Alerts  that  provide  plan-change  recommendations  as 
appropriate. 


4.1  Dashboard  Display 

The  R2D2  Dashboard  display  of  Figure  1  shows  the  Operational  Progress  Timeline  illustrating 
an  operation  involving  the  offloading  of  cargo  from  two  ships  onto  a  train  in  the  context  of  an 
overarching  operation  named  the  Jacksonville  Execution.  The  Cargo  Status  indicator  provides 
dynamic  knowledge  of  the  distribution  of  actual,  planned,  unplanned,  and  unaccounted  for  cargo. 
The  Progress  Metrics  and  Agent  Alerts  that  are  shown  along  the  bottom  of  the  Dashboard 
display  are  described  in  the  following  subsections. 


Figure  1:  R2D2  Continuous  Intelligence  Dashboard  Display 
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4.2  Progress  Metrics 

The  R2D2  Dashboard  provides  configurable  displays  of  the  temporal  and  statistical  metrics  that 
the  R2D2  agent  maintains  for  characterizing  the  ongoing  progress  of  transportation  operations. 
Progress  Metrics  implemented  by  the  R2D2  Proof-of-Concept  include  the  following. 

•  The  Status  metric  indicates  if  the  holistic  transportation  operation  is  on  schedule, 
behind  schedule,  or  not  started. 

•  The  Time  Remaining  metric  indicates  the  time  remaining  until  the  transportation 
operation  is  scheduled  to  end. 

•  The  Avg.  Pcs.  per  Hour  metric  indicates  the  average  number  of  items  that  are 
being  moved  into  their  planned  locations  per  hour. 

•  The  Rqd.  Pcs.  per  Hour  metric  indicates  the  average  number  of  items  that  must 
be  moved  into  their  planned  locations  per  hour  to  complete  the  transportation 
operation  by  the  scheduled  completion  time. 

•  The  Avg.  Dwell  Time  metric  indicates  the  average  timespan  that  items  are 
remaining  in  the  same  area  over  the  course  of  the  transportation  operation. 

•  The  Dead-lined  Cargo  metric  indicates  the  currently  known  number  of  dead-lined 
(i.e.,  inoperable)  cargo  items  that  must  be  accommodated  in  accomplishing  the 
transportation  operation. 

•  The  Cargo  Types  metric  indicates  the  percentage  breakdown  of  cargo  types  (e.g., 
pallet,  vehicle,  break-bulk,  and  container)  that  are  involved  in  the  transportation 
operation. 

•  The  Pcs.  Moved  Since  Last  Analysis  metric  indicates  the  number  of  items  that 
have  been  moved  since  the  last  time  R2D2  performed  its  analysis. 

4.3  Agent  Alerts 

The  R2D2  Dashboard  provides  configurable  displays  at  various  levels  of  filtered  detail  for 
examining  the  alerts  generated  by  the  R2D2  agent  to  indicate  and  describe  potential  planning  or 
execution  issues  as  they  emerge.  Agent  Alerts  implemented  by  the  R2D2  Proof-of-Concept 
include  the  following. 

•  The  Missing  High  Priority  Item  alert  identifies  high  priority  cargo  items  that  are 
currently  unaccounted  for. 

•  The  Planned  Area  Over  Capacity  alert  identifies  conveyance  loading  areas  that 
are  anticipated  to  be  over  capacity  as  a  result  of  several  movement  operations 
utilizing  the  area  at  the  same  time. 

•  The  Unexpected  Dead-lined  Item  alert  identifies  equipment  items  that  have  been 
unexpectedly  discovered  to  be  incapable  of  self-propelled  movement. 

•  The  Items  Did  Not  Arrive  alert  identifies  cargo  items  that  remain  unaccounted  for 
at  the  planned  completion  time  for  the  transportation  operation. 
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•  The  Follow-On  Movement  Impacted  alert  identifies  cargo  items  that  remain 
unaccounted  for,  but  are  specifically  planned  for  in  a  future-dependent 
transportation  operation. 

•  The  Unavailable  Items  alert  identifies  cargo  items  that  are  planned  for  in  the 
context  of  the  transportation  operation  but  did  not  arrive  at  their  previous 
destination. 

•  The  Too  Many  Items  of  NSN  in  Area  alert  identifies  situations  in  which  there  are 
more  cargo  items  of  a  particular  type  within  a  load  area  than  were  planned  for — as 
indicated  by  the  National  Stock  Number  (NSN). 

•  The  Too  Few  Items  of  NSN  in  Area  alert  identifies  situations  in  which  there  are 
less  cargo  items  of  a  particular  type  within  a  load  area  than  were  planned  for — as 
indicated  by  the  National  Stock  Number  (NSN). 
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Attachment  1:  ARTUE  Performance  Improvements 

R2D2  research  identified  the  performance  of  the  NRL  ARTUE  reasoning  engine  as  a  significant 
issue  for  near  real-time  applications  such  as  that  illustrated  by  the  R2D2  demonstration  scenario 
and  container  yard  stacking  investigation.  While  several  improvements  were  made  to  the 
ARTUE  code  base  to  speed  up  the  system  two  in  particular  made  a  significant  difference.  The 
first  change  was  to  replace  the  prototype  rule  engine,  used  for  finding  triggered  notifications,  in 
favor  of  a  faster  third-party  alternative  based  on  Prolog.  The  second  change  replaced  the  Java 
Virtual  Machine  (JVM)-based  execution  of  cognitive  reasoning  services  with  a  faster  native 
solution.  The  results  of  these  improvements,  which  greatly  increased  the  practicality  of 
generating  notifications  based  on  large  plans,  are  shown  in  Figure  2. 

Performance  Testing 

For  the  tests  shown  in  Figure  2,  randomized  operation  objects  were  created  and  run  for  four  (4) 
different  conditions  at  ten  (10)  different  operation  sizes.  Conditions  were  created  for  each 
possible  combination  of  Prototype  or  Prolog-based  rule  engine  and  JVM  or  RPC  reasoning 
communications.  ARTUE  was  tested  at  increments  of  ten  (10)  items  with  between  thirty  (30)  and 
one  hundred  and  twenty  (120)  cargo  items  introduced  per  phase  to  visualize  the  speedup 
generated  by  these  improvements. 


Faster  Rule  Engine 

To  speed  up  rule  firing,  a  number  of  third  party  rule  engine  solutions  were  investigated  for  which 
speed  comparisons  had  already  been  conducted.  Interface  code  was  created  to  re-use  an  existing 
solution,  named  jTrolog,  which  is  known  to  run  quickly  on  the  Java  Virtual  Machine. 
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Experimentation  showed  that  use  of  jTrolog  significantly  improves  performance  over  the 
prototype  rule  engine  as  the  number  of  items  in  a  plan  grows,  avoiding  an  exponential  slowdown 
caused  by  poor  prototype  implementation. 

Remote  Procedure  Call  Server 

The  NRL  ARTUE  engine  was  designed  to  support  a  single  use  case  in  which  all  reasoning  was 
performed  in-process  on  top  of  a  Java  virtual  machine,  despite  the  implementation  of  reasoning 
facilities  in  the  language  Lisp.  Translations  between  Java  and  Lisp  queries  proved  time- 
consuming  as  operations  were  scaled  up  in  support  of  R2D2.  This  prompted  design  of  a  faster 
alternative  wherein  a  separate  server  process,  running  on  the  native  machine  rather  than  a  Java 
virtual  machine,  is  used  to  execution  the  reasoning  code.  Other  Java  services  can  then  connect  to 
the  reasoning  process  as  clients  using  a  standard  Remote  Procedure  Call  (RPC)  interface.  This 
interface  is  available  as  needed.  Experiments  shown  in  Figure  2  recorded  up  to  a  five  (5)  fold 
performance  increase  when  using  the  new  design. 

Asynchronous  Multiple  Access 

While  previous  uses  of  the  NRL  ARTUE  reasoning  engine  required  no  more  than  one 
simultaneous  reasoning  operation,  R2D2  requirements  prompted  need  to  support  parallelism. 
Multiple  R2D2  users  at  different  locations  may  have  different  queries  to  execute  in  ARTUE 
requiring  need  to  serve  them  simultaneously  without  significant  delay.  Therefore,  a  session 
management  component  was  introduced  into  the  new  ARTUE  RPC  server  that  allows  reasoning 
about  two  separate  queries  to  proceed  simultaneously  in  parallel  sessions.  This  improves  both 
response  time  and  turnaround  time  on  client  requests  to  the  ARTUE  Reasoning  Engine. 
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Attachment  2:  Non-Op timal  Stacking  Alerts 

In  response  to  questions  regarding  the  applicability  of  R2D2  technology  to  container  yard 
stacking  problems,  investigatory  design  and  development  was  performed  on  ARTUE  rules  for 
producing  Non-optimal  Stacking  alerts.  This  alert  is  generated  when  an  item  A  is  stacked 
underneath  an  item  B  and  item  A  is  expected  to  move  before  item  B  in  an  upcoming  phase.  The 
alert  offers  an  alternate  stack  order  for  item  A  and  all  items  stacked  above  it. 

The  following  Non-Optimal  Stacking  Scenario  illustrates  this  concept  by  showing  a  potential 
stacking  problem  and  how  R2D2  is  expected  to  respond. 

Scenario  Movements: 

Phase  0: 

1.  Items  A-H  are  stacked  aboard  a  ship  in  reverse  order,  in  3  stacks,  prior  to 
offloading. 

Phase  1: 

1 .  Items  B  and  A  are  moved  to  stack  A 1  -S 1  in  area  A 1 . 

2.  Items  E  and  F  are  moved  to  stack  A 1 -S2  in  area  A 1 . 

3.  Items  C  and  D  are  moved  to  stack  A 1 -S3  in  area  A1 . 

4.  Items  G  and  H  stay  on  the  ship  USS 1 

Phase  2: 

1 .  Items  B,  D,  and  F  are  moved  to  stack  A2-S 1  in  area  A2. 

2.  Item  E  is  expected  in  stack  A2-S1  in  area  A2  but  in  the  real  world  it  is  not 
moved  from  area  A1 . 

During  Phase  2,  R2D2  alerts  users  to  the  Non-Optimal  Stack  F-B  in  Area  2.  This  stack  is  non- 
optimal  because  B  needs  to  move  before  item  F  (i.e.,  in  Phase  3).  ARTUE  also  alerts  users  to  the 
missing  item  E  when  Phase  3  ends.  Figure  3  illustrates  positions  of  boxes  in  ship  and  yard  areas, 
shown  at  multiple  time  points  corresponding  to  the  end  of  abstract  “movement  phases”.  Stacks 
are  shown  as  vertically  arranged  series  of  red  boxes,  with  red  lines  connecting  vertical  neighbors. 
Each  stack  is  named  as  well  as  the  area  it  is  in.  At  the  bottom  of  each  stack,  a  black  striped  box 
indicates  the  ground.  In  the  top  right  comer  of  some  items,  a  small  “e”  indicates  that  the  item 
was  expected  during  the  indicated  phase,  its  absence  indicates  that  no  expectation  existed.  If  an 
“a”  is  present  in  the  bottom  right,  then  the  item  was  reported  to  be  in  the  location  shown  at  the 
end  of  the  indicated  phase. 
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PHASE  0 

Area:  USS  1 
Type:  Ship 


USS1-S3 


USS1-S2 


Area:Al  Area:A2 

Type:  Yard  Type:  Yard 

Al-Sl 


A1-S2 


A1-S3 


Area:  A1 

Type:  Yard 


Figure  3:  Non-Optimal  Stacking  Scenario  Diagram 


Area:  A2 

Type:  Yard 


The  alerts  triggered  by  R2D2  during  the  Non-Optimal  Stacking  Scenario  are  shown  by  phase  in 
Table  1. 


Table  1:  ARTUE-Generated  Alerts  for  Non-Optimal  Stacking  Scenario 


Phase  0 

Phase  1 

Phase  2 

Non-Optimal  Stacking  Item  F, 
E  stack  USS  1 -SI  (Optimal 
Stacking  for  stack  USS  1 -Si:  F- 
E  for  stack  USS  1 -S3:  G-H) 

Non-Optimal  Stacking  Item  B 
stack  Al-Sl  (Optimal  stacking  for 
stack  Al-Sl  A-C-E,  for  stack  Al- 
S3  B-F-D) 

Missing  Item  E  (Area 
A2) 

Non-Optimal  Stacking  Item  F  stack 
A1-S2  (Optimal  stacking  for  stack 
Al-Sl  A-C-E,  for  stack  A1-S3  B- 
F-D) 

Non-Optimal  Stacking  Item  D 
stack  A1-S3  (Optimal  stacking  for 
stack  Al-Sl  A-C-E,  for  stack  Al- 
S3  B-F-D) 
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